1. Field of the Invention
The present invention relates to a program debugging system, and more specifically to a program debugging system for debugging a program having a graphical user interface (conventionally abbreviated to "GUI").
2. Description of Related Art
In the prior art, a program debugging system is widely used in various kinds of data processing systems for the purpose of ascertaining problems in of a developed data processing program.
Referring to FIG. 1, there is shown a block diagram of an example of one typical conventional program debugging system, showing a data processing function and a flow of data processing simultaneously. The shown program debugging system includes a software-based processing means such as a translator program 1207, a linker 1209 and a debugger 1211.
First, how to realize a source program 1206 having a GUI is described.
Most programs having a GUI are realized in the style of an event-driven program. Here, the "event-driven program" means a program constructed to execute any processing if an external factor changes, and the "event-driven program" in a GUI program executes any processing corresponding to a GUI handling when a GUI parts is handled. In addition, in many cases, a system having the GUI is provided with a library having a standard scheme and operation of the system and for realizing an event-driven GUI program operating on the system (called a "GUI library" hereinafter).
In addition to preparing functions of other than a GUI processing (1202), a program developer designs the GUI (1203) using a GUI library 1201, and simultaneously, prepares an operation describing function 1204 describing the operation of the GUI. Thereafter, the program developer relates the designed GUI with the operation describing function (1205), by also using the GUI library 1201. When the program thus designed is executed, at each time the GUI is handled, a corresponding operation describing function 1204 is executed.
A translator program 1207 is a software for translating the source program 1206 written in a high level language, into a machine language program (1208), and a linker 1209 is a software for coupling a plurality of programs (1208) into one program (1210) so as to make it possible that data and subroutines defined in one program can be used in another program. A debugger 1211 is a software used for finding out and removing errors in the developed program (1210).
In general, a van Neumann type computer contains a machine language program stored in a memory, and realizes an operation intended by the developer, by executing instructions of the program. The machine language program is expressed in a train of numeric characters in a binary notification or in hexadecimal notation, understandable to the computer. However, since this train of numeric characters is too complicated for a human being to understand, the program developer prepares the source program 1206 by using an expression easy to understand, and then, translates the source program 1206 into a machine language by the translator program 1206. In an example shown in FIG. 1, since an address is indefinite, each file of machine language program is shown as a relocatable file 1208. Further, the developer uses the linker 1209 to bring the relocatable files 1208 into one program (which is shown as an executable file 1210 in FIG. 1) and stores the program into an external memory of a computer.
In order to confirm unquestionableness of the program thus produced, and in order to investigate a cause of an erroneous operation if the erroneous operation is found out, it is effective to use a verifying program called a "debugger" 1211. When the program is executed on the computer, it is impossible to stop the program at an arbitrary location, and ordinarily, it is possible to recognize no other than information displayed on an output device. Therefore, the debugger 1211 is configured to be capable of executing the program to be debugged, step by step, and of stopping the execution of the program at an arbitrary location. In addition, the debugger 1211 also makes it possible to confirm a program execution condition in the inside of the computer, such as a register and a memory, which cannot be confirmed in the course of an actual program execution on the computer.
Now, how to set a break point in a program to be debugged loaded on a memory and to stop an execution of the program to be debugged at the break point, will be described.
Referring to FIG. 2, there is shown a diagram illustrating a procedure for setting a break point in a conventional program debugging system. More specifically, FIG. 2 illustrates program locations in the memory before and after the break point is set in the program to be debugged loaded in the memory.
A method of executing the program loaded in the memory without modification is possible in the case that an environment under which a program is being developed is the same as an environment under which the program developed actually runs. In addition, in order to set a break point, data of a head line of a machine language at a stop position of the program loaded in the memory is saved, and an interrupt generating code is embedded in place of the saved data.
More detailed explanation of the program location at this time will be made with reference to FIG. 2.
A program location 1301 is a program location in the memory before a break point is set, and a program in a memory region 1302 is a program to be debugged located in the memory. On the other hand, a program location 1303 is a program location in the memory after a break point is set before a line named "L0002".
In the case that an instruction which had put on a break point setting location was saved in a saving memory region 1308, in order to re-start the execution from the saved instruction, a jump instruction for moving the processing to a next instruction address is added in the memory region 1308 so that after the saved instruction is executed, a next instruction will be executed properly. An interrupt generating instruction is embedded at the break point of a memory region 1306 between a memory region 1305 for "L0001" and a memory region 1307 for "L0002". In addition, a debugger routine address of a memory region 1309 is set in an interrupt vector, so that when the interrupt is generated, the processing moves to the debugger routine in the memory region 1309. If the program is executed in this condition, the processing moves into the debugger at the break point, and is brought into a condition for waiting for a command of the debugger. When the debugger receives an instruction of cancelling the setting of the break point, the debugger returns the saved machine language instruction on the execution stopping line, to an original condition.
Incidentally, there is known another method in which, when the debugger executes the program, simulation is executed and stopped by using a simulator means which is a program for simulating execution of the program to be debugged. In this case, a break point setting method is that, the value of an address corresponding to a line of stopping the execution in the simulation execution course, is held, and at each time the simulation of the program to be debugged is executed, the address of the instruction executed is compared with the held address value corresponding to the execution stopping line, and if coincidence is obtained, the processing is moved to the debugger so that the processing is brought into a condition of waiting for a command of the debugger.
Next, a program debugging procedure in the conventional program debugging system will be described about an example that the debugging is conducted by using the debugger 1211 and by setting a break point in a program to be debugged loaded in the memory.
First, a location where the source program 1206 is desired to be stopped for analysis, namely, a break point is searched. If the break point is determined, a command for instructing to stop the processing at the determined break point is delivered to the debugger. The command is delivered either by inputting a word indicative of the command (called simply a "command" hereinafter) and the number indicating the line concerned in the source program, by use of a key board of the computer, or in a debugger capable of displaying the source program, by designating the line concerned by use of an input means indicating a location in the source program on a display screen (called a "pointing device" hereinafter). In general, the machine language program to be debugged includes information which is not used in actual execution but is referred to only when the debugging is executed. For example, the machine language program to be debugged includes information indicating what line of the source program corresponds to the machine language concerned, so that when the source program is indicated on the display screen of the debugger, the source program itself is displayed in place of displaying the machine language.
In particular, when a program having the GUI is the program to be debugged, one break point setting method includes retrieving the program to be debugged, so as to find out an operation descriptor, and to select a location of the operation descriptor as a break point setting location. For this purpose, the source program is retrieved to find out an operation describing function name within the source program by using a program editor (program editing program) on the basis of the developer's memory and documentary records at the time of preparing the program. If this is impossible, the source program is sequentially retrieved by the program editor to find out the GUI library function name, and then, whether or not the found-out GUI library function is a target GUI library function is discriminated on the basis of how the found-out GUI library function is used, and if so, a registered operation describing function name is confirmed by using the GUI library function, and thereafter, a retrieval is conducted again to find out the operation describing function name, in order to determine the break point setting location.
Referring to FIG. 3, there is shown a flow chart illustrating the procedure for setting the break point for the operation describing function in the program having the GUI. As shown in FIG. 3, the processing is started from a step 1401. In a step 1402, whether or not the operation describing function name is remembered is discriminated, and if it is remembered, the operation goes to a step 1409 in which the source program is retrieved to find out the operation describing function name, and then, a break point is set in a step 1410. If the operation describing function name is not remembered, whether or not a design specification exists is discriminated in a step 1404. If the design specification exists, the operation describing function name is investigated from the design specification in a step 1403, and thereafter, the operation goes to the step 1409.
If the design specification does not exist, the operation goes to a step 1405 in which the source program is retrieved to find out the GUI library function name for registering the operation describing function. Thereafter, in a step 1406, how the found-out library function is used is investigated, and in a step 1407, whether or not the found-out library function is the target GUI library function to be found out. If the found-out library function is not the target GUI library function, the operation returns to the step 1405, and the operation of the steps 1405 to 1407 is repeated until the target GUI library function is fount out. If the target GUI library function is found out, the operation goes to a step 1408 in which the registered operation describing function name of the found-out GUI library function is confirmed by utilizing the GUI library function. Thereafter, the operation goes to the step 1409 in which the source program is retrieved to find out the operation describing function name within the source program, and then, the break point is set in the step 1410.
After the break point is sets it starts to execute the program. After the execution is stopped at the break point, the internal status is displayed by using the command, and whether or not the internal status is coincident with the result predicted by the developer is confirmed. If coincidence is not obtained, whether or not an incorrect description exists at the stop position is ascertained. If the incorrect description exists, the incorrect description is modified or corrected. If the internal status is not coincident with the result predicted by the developer but an incorrect description does not exist at the stop position, an internal status ascertaining operation is repeatedly conducted while stopping the operation at a different location relating to the stop position.
In the above mentioned conventional program debugging system, a program analyzer at the debugging time is a program developer. Therefore, if the size of the program is on the order of several hundred steps, it is possible to relatively easily identify the location to be analyzed. However, in the case of developing a large scale program amounting to several ten thousand steps, it is difficult to grasp the program in detail.
Furthermore, if a plurality of developers simultaneously modify the source program, the source program is changing every moment, and on the other hand, the program analyzer often analyzes a location other than the locations prepared by the program analyzer himself. In this case, materials referred to at the time of preparing the program do not often remain, and this becomes a hindrance in analyzing the program.
In addition, in the case of the program having the GUI, although the operation of the GUI parts is shown on the display screen, when the break point is set, it is necessary to analyze the program in order to find out the operation descriptor of the GUI parts. This is troublesome.